+1'd comment on post by Friends+Me in Google+ Help+Julian Bond I think we'll have to agree to disagree. Though, I am confident if you republished content of mine I had shared to a community that you owned, I would have a strong legal position to claim you did not have any express permission to do so. And that's without getting onto the subject of copyright. To get express permissions from all members of a community with more than a few hundred members may well be impossible, and without express permission, (which is different to implied permission), I believe you would be entering the sticky ground of potentially being in breach of GDPR. I'm prepared to admit I'm not a legal expert, and this is just my interpretation of my understanding of current legislation. Some may argue that implied permission is enough, and was granted when they posted the content to your community. While you may 'own' the community, you don't necessarily own the content posted to it. I'm not sure where the "google shouldn't or couldn't" you are quoting is from, and am a little confused as to your inclusion of it here. I can only assume you are quoting me, and my thoughts on the matter, as though I am speaking on behalf of Google, which I am not. Some may indeed see it as a 'need', though I'm not so sure it is a valid need or indeed something that Google will facilitate or improve upon. I agree that the takeout data is confusing, and hopefully recent updates to the Takeout Help File have provided a little clarity here. https://support.google.com/plus/answer/1045788?hl=en As for general feedback on how Takeout currently works, and aspects that are lacking, that is hopefully something that will evolve and improve over the next few months. — Good news everyone, We've released Google+ Exporter, an application that helps you to export your Google+ feeds (profile, pages, collections, communities, including all comments) to Wordpress eXtended RSS file. Another available option is to export all posts published to profile, pages, collections, and communities to JSON file, including all comments! Export up to 3000 posts with our free version. I would love to know your opinion, suggestions or requests. Thank you!
+1'd comment on post by Edward Morbius in PLExodus: The Beginning is NearI've only just noticed that the Members.vcf has only a fraction of the user count of the community as presented on the web. I wonder which fraction, and why. — G+ Communities Rank-Size plot, based on 12,000 obs. sample The rank-size relation is a common feature of most population and group studies, see: http://www.statisticalconsultants.co.nz/blog/the-rank-size-rule-of-city-populations.html Plotting log-log of size (population or members) vs. rank (sorted order), a linear relation generally emerges. We see that here. The actual y-intercept should be about 4.3 million (Photography community), but the mainline sample, from about n=10 to n=1,000 gives a good fit. Values here are based on a 12,000 observation sample, multiply ranks by about 600 to get the full Communities estimate. More on analysis: https://old.reddit.com/r/plexodus/comments/9zx67d/google_communities_membership_analysis_preview/
+1'd comment on post by The Annoyed Atheist in Google+ Help+Julian Bond THANKS!! Yes I have thousands of photos, and yes they are downloading right now from zip files. It worked. Thanks again!! Someone should post these instructions for all to see! It would help lots of people I am sure. Thanks again and Happy Thanksgiving!! — I would like to know if there is anyway to mass download all of my photos to my personal computer? I looked in my Google photos and most of them are missing and I don't really want them on Google Photos. Is there anyway to download them totally without doing them one by one?
+1'd comment on post by Julian BondThese free sites make money on ads so it makes sense that they want to drive traffic to visit their page and not allow for automated cross posting. I've certainly seen that people who do automated cross posts are less likely to respond to comments on those posts because they aren't actually visiting the site. I see your problem getting worse not better as people try to become the sole social media site. — Once upon a time, I used to route G+ public posts to my blog, Twitter, Facebook. The idea was "Post once - Cross-post everywhere" . So I posted once on G+ and the system cross posted the article or a subset of it to all the other platforms. This originally used http://dlvr.it but then they stopped reading G+. I was never completely happy with the layout. And I needed to code for this in my own blog anyway, so I wrote a G+ post to Atom convertor. This gave me an Atom feed to push into http://dlvr.it as well as a source for my blog to auto-create posts. Then Facebook stopped allowing external apps to post on a personal timeline. This process always had to start with G+ because that didn't have a write API. It could only be a source for cross posting, not a sink. http://dlvr.it and IFTTT have become less and less useful as they monetise and keep reducing support for free users. Meanwhile, new systems started to turn up with their own APIs like Mastodon, Diaspora, Hubzilla, etc. But even though they use standardised protocols, they're still too small to get any traction with things like http://dlvr.it and IFTTT. And now G+ is closing down. So it can't even be a source any more. And there's no obvious way to get posts out of Facebook as they disabled Atom feeds out of Facebook long ago. So what with the snowflake API problem, free services getting monetised and closed and walled gardens adding barbed wire to the top of the walls, this approach is reaching the end of the road. Maybe the idea of "Post once - Cross-post everywhere" has become impossible. It's certainly hard to work out where to start.
+1'd comment on post by Julian Bond in Google+ Mass MigrationIf I’m on many platforms and i see the same post, yes it is annoying and spam like. If I’m on only one, and thus get to see the post im interested in, its not. I’d rather be on 1 not 2, or 2 not 3 platforms, etc. If with g+ dying a community fragments then cross posting maintains contact with some reasonable share (potentially) of the original audience. So i can see how it can be seen to be of value and not necessarily misguided. I join different groups - facebook or g+ or whatever, for different content. Not services. They may be /on/ different services but it is the /group/ that is important. But with g+ dying I’m looking to be looking to be joining different services for the same content, particularly if people i follow here go to 3-5 different services. So it isn’t quite that simple. Either way has reasons and justifications - and will equally annoy others it seems. — Once upon a time, I used to route G+ public posts to my blog, Twitter, Facebook. The idea was "Post once - Cross-post everywhere" . So I posted once on G+ and the system cross posted the article or a subset of it to all the other platforms. This originally used http://dlvr.it but then they stopped reading G+. I was never completely happy with the layout. And I needed to code for this in my own blog anyway, so I wrote a G+ post to Atom convertor. This gave me an Atom feed to push into http://dlvr.it as well as a source for my blog to auto-create posts. Then Facebook stopped allowing external apps to post on a personal timeline. This process always had to start with G+ because that didn't have a write API. It could only be a source for cross posting, not a sink. http://dlvr.it and IFTTT have become less and less useful as they monetise and keep reducing support for free users. Meanwhile, new systems started to turn up with their own APIs like Mastodon, Diaspora, Hubzilla, etc. But even though they use standardised protocols, they're still too small to get any traction with things like http://dlvr.it and IFTTT. And now G+ is closing down. So it can't even be a source any more. And there's no obvious way to get posts out of Facebook as they disabled Atom feeds out of Facebook long ago. So what with the snowflake API problem, free services getting monetised and closed and walled gardens adding barbed wire to the top of the walls, this approach is reaching the end of the road. Maybe the idea of "Post once - Cross-post everywhere" has become impossible. It's certainly hard to work out where to start.
+1'd comment on post by Julian BondGooglePlus was always my original source, or social home for short to medium form content. I'd only blog when I wanted more space and functionality. Now I'm planning on blogging more and use Twitter for the short form stuff. I stand by the notion that Google pulling the plug on GooglePlus is an ill thought out bad idea on Google's part. — Once upon a time, I used to route G+ public posts to my blog, Twitter, Facebook. The idea was "Post once - Cross-post everywhere" . So I posted once on G+ and the system cross posted the article or a subset of it to all the other platforms. This originally used http://dlvr.it but then they stopped reading G+. I was never completely happy with the layout. And I needed to code for this in my own blog anyway, so I wrote a G+ post to Atom convertor. This gave me an Atom feed to push into http://dlvr.it as well as a source for my blog to auto-create posts. Then Facebook stopped allowing external apps to post on a personal timeline. This process always had to start with G+ because that didn't have a write API. It could only be a source for cross posting, not a sink. http://dlvr.it and IFTTT have become less and less useful as they monetise and keep reducing support for free users. Meanwhile, new systems started to turn up with their own APIs like Mastodon, Diaspora, Hubzilla, etc. But even though they use standardised protocols, they're still too small to get any traction with things like http://dlvr.it and IFTTT. And now G+ is closing down. So it can't even be a source any more. And there's no obvious way to get posts out of Facebook as they disabled Atom feeds out of Facebook long ago. So what with the snowflake API problem, free services getting monetised and closed and walled gardens adding barbed wire to the top of the walls, this approach is reaching the end of the road. Maybe the idea of "Post once - Cross-post everywhere" has become impossible. It's certainly hard to work out where to start.
+1'd comment on post by Joerg Fliege in Brexit, SchmexitWell, back in those days people seemed to believe war is something to better avoid. This definitely has changed. War is being seen as something honourable now. — The pro-European campaign in 1975 had a certain bluntness to it. Also, this wasn't all about market access: another Brexit lie.
+1'd comment on post by Joerg Fliege in Brexit, Schmexit+Thilo Fromm That scares me. War is brutal and savage. All anyone needs to do is look at Syria (as but one of a long list of recent events since WWII). The conflict in the Balkans War/Conflict is a horrible example of how it can happen again, here in Europe. The scars from that war are festering. Anyone who prefers money to war is forking dangerous! — The pro-European campaign in 1975 had a certain bluntness to it. Also, this wasn't all about market access: another Brexit lie.
+1'd comment on post by Joerg Fliege in Brexit, SchmexitJust get on with making a complete and utter bollocks of it so finally, we can have our independence referendum in Scotland and tell Westminster to, “Fuck off”. — Sky Data poll from today. Which Brexit outcome would you prefer? No Brexit - 54% No deal - 32% May's deal - 14% Should we have a second EU referendum? Yes - 55% No - 35% Who would you prefer to lead the country through Brexit? Theresa May - 31% Jeremy Corbyn - 25% Jacob Rees-Mogg - 18% Boris Johnson - 17% Dominic Raab - 10% This is all reasonably encouraging, except for the last question, where 45% of all polled are in favour of Moggie, Dom, or Boris. Whats the plan here? Barreling full force towards a Mad Max future?
+1'd comment on post by Julian Bond in Google+ HelpWe’re currently trying to clarify the situation regarding this. — I'm confused by the relationship between G+ Circles and Google Contacts. The old Google Contacts interface used to have a section for your circles. And viewing people in it, brought up the publicly visible parts of their profile with things like Telephone numbers. The new preview Google Contacts interface doesn't have any reference to circles. But if you export your circles with G+ Takeout and then import the files into Contacts, people in your circles now have an entry. But there's almost no information there. You get name, a link to their google profile and that's it. Go back to the old interface, and the person appears twice. Once with minimal info in the main contacts. And again in the circles section. So is Google Contacts linked to G+ or not? Is there any point in importing Takeout.G+Circles files into Contacts?
+1'd comment on post by Joerg FliegeYou realize Google Groups became operational in 2001 and it is of that timeframe of which I speak. — So, not understanding online social networks is an age thing. (Claims Schmidt in a roundabout way.) Really? Everybody in charge at Google was too old for Usenet?
+1'd comment on post by Julian Bond in Google+ Mass MigrationA whole 'nother set of factors revolves around interactions, which is mostly notifications. Notifications tend to be: * Messages from other users/groups. * Actions from other users/groups: mentions, activity-on-thread, activity-in-channel. * System notifications which may be news, features, status updates, or other site-wide / system-wide activity. * Periodic summaries such as daily/weekly/monthly round-ups. * Management/moderation issues. Flags, spam, etc. * Requests for you to act on. * Notification of your requests acted on. * Recommendations, generally content, users, topics, channels, etc. * Task completion for your requests which don't complete interactively (typically 1+ minute duration, may take days or more.) * Scheduled notification of events or reminders. * Requests for live/interactive sessions such as live chat, voice, or video. * Alternate-media streams within a chat such as text or alternate video (slides, etc.) in a voice or video chat. * Issues alerts for group, channel, instance/hub/pod administrators, programmers, etc. The principle points of notifications are to prompt for engagement. In most cases, notifications are very strong indicators of intentionality. That is, the notified user is almost always being alerted to an item with which they've already interacted and which someone else is also interacting. That is, in the world of social media which is mostly dead, write-once, read-never content, two lost souls in the vast abyss have actually met and shared an interest. This isn't _always a good thing, but it may be. The biggest problem with notifications is that there is a sweet spot for human notification frequency. It's probably on the order of 3-30x daily. Less than that risks being too low, more than that, annoying. The range is staggeringly narrow by most information technology standards. That is, it's very easy to design systems that generate too few, or too many, notifications, and in most cases both at the same time for different users, or for the same user at different times. I've had some informal experience at monitoring this myself over the past month as the interactions I've had with G+, Diaspora, Reddit, and Email have all spiked. Above about 30-60 notifications/day I start getting testy, and at the 200+ level, that's spilling over into real life, quite notably. I've commented at length at the Dreddit on daily informational volumes and note that Stephen Wolfram and Walt Mossberg each note about 100-300 emails/day, though Wolfram (who's measured this over decades) actually sends no more than about 50, and his daily receipt mode is also in the 25-50 range, it's that the tail is long and can run higher. The New York Times comments moderation team nets out to fewer than 800 messages/day each, which is roughly a comment every 30 seconds over an 8 hour day -- I presume there are breaks and other tasks. The notifications system should filter for relevance and allow addressing the needs of the notification directly within the page. Google+ (desktop), Ello, Hacker News, Mastodon, and Reddit generally provide for this. Diaspora does not, nor does G+ Mobile Web. Reddit doesn't allow for moderator actions to be managed in the Notifs view. And virtually no email-based notifications systems allow for this (mailing lists and the Debian Bug Tracking System are notable exceptions). Among the elements that made Imzy so bad, particularly under abuse, was that not only were the Notifications non-addressable, but they were intentionally opaque and when navigating to a discussion there was no clear way to see what specific new item had prompted the notification. The flat discussion thread at G+ has its annoyances, _but one thing it does is make clear where the newly-added comments on a thread are. Most Web-based threaded feeds don't do this (see, e.g., Reddit or HN). Old-school threaded mail (mutt) and Usenet (rtin, Netscape's newsreader) did support this, and that was an underappreciated strength. Being able to interactively filter and search notifications is a key strength. Again, Mutt has some strong benefits here, and the ability to apply context-aware filters (sender, subject, date(s), arbitrary headers, body text) simply and quickly is an underappreciated strength of that tool. Google+'s Notifications tool has its frustrations but is actually one of the site's key features and strengths. It's what lets conversations live. Modulo idiots coming in and wasting time. (The inability to filter out certain interactions is ... its key weakness.) Diaspora's Notifs page is useful in that it's possible to filter and mark-as-read minor stuff (likes, shares, etc.), but it is dog slow at going through comments-on-posts or mentions. The only activity which can be directly responded to on the Notifs page is new-user follows. *The ability to time-box or time-silence notifs for some period would be hugely useful. Hour, day, week, month, year. Post/thread, user, community/group, category. It's something I've long requested on many platforms. (My usual alternative is to find the respective CSS element and disable its display entirely.) — Some thoughts on ways of categorising Social Networks along different dimensions. Network effects There is power in size. The question is, how much power? Metcalfe looked at it via the number of 1-1 connections possible and decided it was proportional to the square of the total number of nodes. This is one reason why Facebook or Twitter have more potential network power than G+. So the utility rise not just with N but N^2 Reed took this a stage further and looked at group forming and the total number of potential groups. The total number of possible groups is 2N - N - 1 suggesting that Utility rises in group forming networks at 2^N. However in real world networks nowhere near all possible groups actually form. In Social Groups it seems to me you need a minimum of 5 noisy people for the group to be self-sustaining. On the usual basis that 90% lurk, 9% Comment and 1% post, that means the real lower end is more like 50 people. At the upper end, Dunbar's number steps in as groups become too big for everyone to know each other. Somewhere around 150-250 people, groups tend to fragment. So as well as Social Networks gaining utility with N^2, if they support groups, their utility rises at somewhere between N^2 and 2^N. So for a Social Network to have long term utility we need lots of people able to form 1-1 relationships. And the ability to form small (5-250), long lived groups around common interests. The open question right now is whether we can build another truly large scale system (tens of millions of users, tens of thousands of groups) on top of a federated architecture or if this requires Google/Twitter/Facebook scale centralisation. https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Reed%27s_law One-Few-Many A long time ago now, I had the idea of categorising communication systems and platforms according to the numbers of creators and the number of consumers. Or authors and readers. Break each side into "One", "Few", "Many" and you have a 3*3 matrix of One-Few-Many authors communicating with One-Few-Many readers. So Private Blogs are typically One-to-Few. Big Media broadcast outlets are One-To-Many. Discussion forums are Few-To-Few. a person's experience of Feed aggregators is Few-To-One. Private messaging is generally One-to-One. eBay is Many-to-Many. Filling out all the cells in the matrix is an interesting intellectual exercise. The point though is that there are fundamental differences here between the various styles of comms. https://www.voidstar.com/node.php?id=2977 https://www.voidstar.com/images/onefewmany.gif Sync-Async Or Sync-real time, nearly real time, Async. How is the style of our comms defined by time? Chat and group chat (like IRC) happen almost in real time. People sometimes try and use Twitter or Email like this but it really doesn't work that way. We then bolt notification systems on top of this to try and speed up the responses and encourage people to respond immediately. But of course this breaks people's natural workflow. It also encourages a lack of thought in the reply. Often what's actually needed is a conscious decision to make the comms Async. Don't expect a reply in 24 hours and the reply you get is likely to be more thoughtful. Media Text, voice & image, video. There's a real problem with communications that use a tool that is too high up the stack here. This also relates back to the Sync-Async problem. Don't interrupt me with a voice message when I could skim read the text in my own time. But also don't use a screen shot just because of platform limitations (Twitter!). And don't do a 5 minute video to camera when 300 words would do that I could skim read in 20 seconds. But each media type as it's place. Your text review is no substitute for listening to the music or watching the film. But don't force me to watch the 45 minute TED talk to grok your 5 page idea. TL;DR. is bad, but TL;DV. is worse. Post Size Micro, Small, Long. There are fundamental differences in style between 140 chars, one screen of text and a 5 page essay. Every time we impose a limit the users will try and find ways round it. Hence Unroll, and reply-to-self /N conventions. Ideally, any one platform should support all these and not differentiate. In practice, dropping a 1000 word block into a chat doesn't work. But that's actually obvious. What isn't obvious but should be is that long form text is important. And somewhere in social networks there should be support for this. A long form post with semi-threaded short form comments below it is a highly successful pattern so should be supported.
+1'd comment on post by Julian Bond in Google+ Mass Migration+Julian Bond I suspect you've already seen, but: "Defining Platform Capabilities" https://plus.google.com/104092656004159577193/posts/136zsC5njrC Also the Suggested Fields section of the Platforms and Sites #PlexodusWiki page: https://social.antefriguserat.de/index.php/Platforms_and_Sites#Suggested_Fields +Gideon Rosenblatt +Christian Buggedei +Carsten Reckord +Luc Jallois should be looking at this also. +Ed S +Shelenn Ayres +Filip H.F. Slagter Scale: One-Few-Many is good, though the question of where to draw the line between "few" and "many" (and possibly "one" and "few") comes up. I've been inclined to treat networks as log(10) scale: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. We might be able to compress that somewhat: 0, 1, 2, 3, 6, 9. The thing is that there are different behaviours and dynamics which appear even at the larger size scales. Sync-Async: This raises some interesting elements. One is the streaming vs. message-passing aspect. See also Jacob Nielsen's "Time Scales in User Experience": https://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/ Some thresholds, I've added to Nielsen's descriptions: 0.1s: users to feel like their actions are directly causing something to happen on the screen. Upper limit for realtime voice/video latency. 1s: users feel like they're navigating freely 10s: Upper bound for maintaining task flow 1m: complete simple tasks 10m: a long visit to a website. 1 day: turnaround for customer service requests. Hotfix cycle. 1 week: Tasks that require extensive research or big decisions. Habitual activities. Bugfix cycle. 1 month: Business process cycle. Software sprint. 1 year: Time to become an experienced user. Software major release cycle. 10 years: Time develop deep expertise in a complex system. Data lifespan. 100 years: Social change scale. Compare: latency numbers every programmer should know: https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html Where sync processing generally involves signals, async processing generally involves records. In the infotech world, there's some blurring of these concepts, though the essence holds: Signals are messages transmitted through space by variation in time between a transmitter and a receiver. Records are messages transmitted through time by variation in space between a writer and a reader. (A given message may transition through signal and record states, multiple times and rapidly in a computing context. Generally, if the primary variance is in space you're dealing with records, if time you're dealing with signals.) Media. My earlier explorations are of text of varying levels of structure, images, audio, video, multimedia, structured data, and complex formats. SMS and microblogging typically have low-complexity text -- essentially character and punctuation strings, often with only character space (no linefeed). At the other end are complex typeset documents with complicated characters, positions, styling, etc. Images/audio/video are pretty self-explanatory. "Structured data" is something that requires a specific data parser. This might be standardised formats (RFC2822 message formats, MIME, HTML) or nonstandard -- database exports, etc., which require field-based parsing and ETL (extract, transform, load) cycles. Post size. I've been mucking around with a bunch of concepts of text size, particularly as I make heavy use of index cards for my own note-keeping. A 4x6 index card holds roughly 150 words (15 lines). Ten can be easily spread on a surface, 100 are a readily managed stack, 500 a typical purchase bundle, 3,000 fit in a storage box. Ten boxes is a substantial research archive. Generally (and rough values): Bit, byte, word, character: single entity, 8 bits/byte, 6 bytes/word (English) Line: ~60-80 characters, ~10 words. Page: ~250 words, about 40 lines. Chapter/Essay: About 4-25 pages, 1,000 - 6,000 words, about the maximum length of a Reddit post (40,000 chars). Short book: ~120 pages, ~10 chapters, 30,000 words. Large book: ~500 pages, ~20 chapters, ~125,000 words, 5 MB text PDF, 50 MB image scan. Book shelf: 25 books (avg. 250 pp), 6,250 pages. (~3 linear ft/1 linear meter) Book case: 8 shelves, 200 books. Aisle: 8 book cases, 64 shelves, 1600 books, 8 GB (text PDF). 1 Row: 8 aisles, 32 cases, 12,800 books. 1 Floor: 8 rows, 102,400 books. Library: 12 floors, 1.2 million books. (6 TB PDF) Campus: 8 libraries: 9.6 million books (48 TB PDF) The US Library of Congress is the largest single library collection in the world at ~40 million books: The Library of Congress is the largest library in the world, with more than 167 million items on approximately 838 miles of bookshelves. The collections include more than 39 million books and other printed materials, 3.6 million recordings, 14.8 million photographs, 5.5 million maps, 8.1 million pieces of sheet music and 72 million manuscripts. https://loc.gov/about/fascinating-facts/ That works out to 28.9 books/meter, or 26.4/yard, validating my semi-WAG above. I typically see about 5 MB for PDFs, about 50 MB for image-scanned books. Audio in MP3/OGG format is about 18h/GB, video is about 15 min/GB in 720p DVD format. Images/GB varies considerably with resolution and format, from a high of 715/GB (4MP JPG) to a low of 13/GB (22 MP RAW), see: https://kb.sandisk.com/app/answers/detail/a_id/69/~/number-of-pictures-that-can-be-stored-on-a-memory-device The iPhone XS features a 12 MP camera (rear), 238/GB in JPG format. A current high-end DLSR (FujiFilm X-T10) features 16.3 MP, 178/GB JPG format. (I'm assuming these won't be shared in raw format.) The high-end Nikon D500 runs 20.2MP. 1,000 images at 22MP is about 8 GB. For some real-world image storage stories: "Facebook Builds Exabyte Data Centers for Cold Storage" (2013) https://www.datacenterknowledge.com/archives/2013/01/18/facebook-builds-new-data-centers-for-cold-storage Facebook stores more than 240 billion photos, with users uploading an additional 350 million new photos every single day. To house those photos, Facebook's data center team deploys 7 petabytes of storage gear every month. But not all of that photo data is created equal. An analysis of Facebook's traffic found that 82 percent of traffic was focused on just 8 percent of photos. FB maintains three storage tiers. All are instantly available ("cold storage" is not tape), though with differing availability. FB had 1.06 billion MUA as of December 2012, or https://www.yahoo.com/news/number-active-users-facebook-over-230449748.html This works out to 650 KB/image, or 156 petabytes total storage, or 148 MB/user, on average. (There's almost certainly a very wide range of image storage patterns.) Storage may include non-image data, it's unclear from the article. FB has a limit of 1,000 images/album and 200 albums/user, or 200k photos/user. https://www.quora.com/Is-there-a-storage-limit-on-Facebook As of 2010, FB were running ~60,000 servers for ~1 billion MUA, or about 16,700 users/server. Counts as of 2016 were thought to be hundreds of thousands. https://www.datacenterknowledge.com/data-center-faqs/facebook-data-center-faq FB expanded to 300 PB (petabytes) total storage in 2014: https://code.fb.com/core-data/scaling-the-facebook-data-warehouse-to-300-pb/ Incoming daily data was 600 TB. I'm going to tackle some other dimensions in another comment. — Some thoughts on ways of categorising Social Networks along different dimensions. Network effects There is power in size. The question is, how much power? Metcalfe looked at it via the number of 1-1 connections possible and decided it was proportional to the square of the total number of nodes. This is one reason why Facebook or Twitter have more potential network power than G+. So the utility rise not just with N but N^2 Reed took this a stage further and looked at group forming and the total number of potential groups. The total number of possible groups is 2N - N - 1 suggesting that Utility rises in group forming networks at 2^N. However in real world networks nowhere near all possible groups actually form. In Social Groups it seems to me you need a minimum of 5 noisy people for the group to be self-sustaining. On the usual basis that 90% lurk, 9% Comment and 1% post, that means the real lower end is more like 50 people. At the upper end, Dunbar's number steps in as groups become too big for everyone to know each other. Somewhere around 150-250 people, groups tend to fragment. So as well as Social Networks gaining utility with N^2, if they support groups, their utility rises at somewhere between N^2 and 2^N. So for a Social Network to have long term utility we need lots of people able to form 1-1 relationships. And the ability to form small (5-250), long lived groups around common interests. The open question right now is whether we can build another truly large scale system (tens of millions of users, tens of thousands of groups) on top of a federated architecture or if this requires Google/Twitter/Facebook scale centralisation. https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Reed%27s_law One-Few-Many A long time ago now, I had the idea of categorising communication systems and platforms according to the numbers of creators and the number of consumers. Or authors and readers. Break each side into "One", "Few", "Many" and you have a 3*3 matrix of One-Few-Many authors communicating with One-Few-Many readers. So Private Blogs are typically One-to-Few. Big Media broadcast outlets are One-To-Many. Discussion forums are Few-To-Few. a person's experience of Feed aggregators is Few-To-One. Private messaging is generally One-to-One. eBay is Many-to-Many. Filling out all the cells in the matrix is an interesting intellectual exercise. The point though is that there are fundamental differences here between the various styles of comms. https://www.voidstar.com/node.php?id=2977 https://www.voidstar.com/images/onefewmany.gif Sync-Async Or Sync-real time, nearly real time, Async. How is the style of our comms defined by time? Chat and group chat (like IRC) happen almost in real time. People sometimes try and use Twitter or Email like this but it really doesn't work that way. We then bolt notification systems on top of this to try and speed up the responses and encourage people to respond immediately. But of course this breaks people's natural workflow. It also encourages a lack of thought in the reply. Often what's actually needed is a conscious decision to make the comms Async. Don't expect a reply in 24 hours and the reply you get is likely to be more thoughtful. Media Text, voice & image, video. There's a real problem with communications that use a tool that is too high up the stack here. This also relates back to the Sync-Async problem. Don't interrupt me with a voice message when I could skim read the text in my own time. But also don't use a screen shot just because of platform limitations (Twitter!). And don't do a 5 minute video to camera when 300 words would do that I could skim read in 20 seconds. But each media type as it's place. Your text review is no substitute for listening to the music or watching the film. But don't force me to watch the 45 minute TED talk to grok your 5 page idea. TL;DR. is bad, but TL;DV. is worse. Post Size Micro, Small, Long. There are fundamental differences in style between 140 chars, one screen of text and a 5 page essay. Every time we impose a limit the users will try and find ways round it. Hence Unroll, and reply-to-self /N conventions. Ideally, any one platform should support all these and not differentiate. In practice, dropping a 1000 word block into a chat doesn't work. But that's actually obvious. What isn't obvious but should be is that long form text is important. And somewhere in social networks there should be support for this. A long form post with semi-threaded short form comments below it is a highly successful pattern so should be supported.
+1'd comment on post by Edward Morbius in Google+ Mass Migration1. Why was 'originalContent' removed from Google+ Stream Posts JSON data, and can it be added back to the Takeout data? Early on (at least around 2013) Takeout archives had significantly different data in their JSON, in a structure that more closely matched the format documented in the Google+ API and the google-api-client (at least the one written in Ruby). The current format however differs greatly, especially w.r.t. Access Control Lists (Acl), and especially lacks the 'originalContent' data, which contained the content of the Activity (the generic resource name for Posts and other content on G+) as it was originally submitted, rather than only the HTML-formatted data in the 'content' key. I understand the need for refactoring the Acl datastructure to account for new Acl settings for for instance Collections, however I don't quite understand why the originalContent data was removed? I would highly appreciate this data being added back. Why? Google+'s HTML formatted text didn't always reflect the intended original formatting, especially in the early days. G+'s forced auto-linking of text containing @signs also has a tendency to make non-account references (especially Mastodon profile addresses, e.g. @ FiXato @ mastodon.social (without spaces) would get changed to +) illegible. tl/dr (1): please add the unformatted, original source post bodies (originalContent) back to the Google+ Stream Posts Takeout archives data 2. What will happen to other platforms that still offer some form of integration with Google+, Blogger in particular? Some other platforms still offer integration options with G+, in particular your own blogging platform Blogger/Blogspot comes to mind. Blogger for instance offers the options to use Google+ for top-level comments and to automatically share the new entries to Google Plus. Important to note though is that at least 4 of the 'Help' links regarding Google+ Comments inside Blogger are no longer working: = https://www.blogger.com/go/private-blog-disabled (Help link for Settings/Basic/Blog Readers/"Google+ Comments enabled") = https://www.blogger.com/go/gpluscommentshelp ("Learn More" link for Settings/Posts, Comments & Sharing/"Use Google+ Comments on this blog") = https://www.blogger.com/go/gplussharehelp ("Learn More" link for Settings/Posts, Comments & Sharing/"Auto-share new published posts to your Google+ profile") = https://www.blogger.com/go/gplustabhelp ("Learn More" link for Settings/Posts, Comments & Sharing/Share to Google+/"Associating your blog") 2a. what will happen to comments on Blogger articles that were submitted using the Google+ Comments system? Will you offer an option to convert them into Blogger-native comments, will they turn into read-only legacy G+ comments, or will they just disappear completely after Google+ has been shutdown? 2b. what will happen to the automatic Share To Google+ option for new Blogger articles? Will it be replaced with new auto-share options, or just silently disappear? 2c. what will happen to Blogger blogs that currently have Google+ set as User Profile? (Settings/User Settings/General/User Profile) tl/dr (2): please allow for conversion of Google+ Comments on Blogger articles to native Blogger Comments, and list other platforms affected by GPlus' shutdown, and fix help links on Blogger. 3. What will happen to Google+ Pages aka sub-account profiles. This is rather related to the previous section of questions, as it's mostly about integration with other platforms, but due to its potential impact, I decided to list it separately. Within your Google/Google+ main profile, you were allowed to create Google+ Pages, which were/are basically stand-alone sub profiles which (theoretically) shouldn't be publicly traceable to your main profile. As such, quite some users opted to create one or more of these, to separate their online identities, especially during the early days when the Real Name Policy was still in effect, as Pages were not necessarily affected by the Real Name Policy. Especially during the forced YouTube/Google+ integration, one of the options was to create a Google+ Page for your YouTube channel, and bind your YouTube account to that, rather than the main Google Profile. Myself, as well as likely a sizeable amount of other YouTube users, picked this option, rather than to bind it to my main Google Profile, or to create a new Google Profile. Currently my main YouTube channel is still linked to my Google+ Page. What will happen to these Pages and YouTube accounts? Within Blogger as well, you have the option to post from your Google+ Page identities, as well as to auto-share to your Google+ Page identity. Will you continue to be able to switch to these Pages (sub-)accounts from within your main Google profile, even after Google+ has shut down? Will there be a migration option to turn them into full-blown, stand-alone, Google profiles? Or will they disappear completely? tl/dr (3): what will happen to Google+ Pages, and their use as login accounts for YouTube and Blogger? Is there a migration path? 4. Why haven't we been contacted by e-mail yet about the upcoming Google+ Sunset? The Google+ Sunset was first announced as a side-note on the Google Security blog, even before it was announced by the +Google+ Google+ account. Neither of these are sources every Google+ user typically reads. Most of us heard the news through third parties like other Google+ users, or news media outlets. However, this still does not cover all Google+ users. Even yesterday a friend of mine had to hear of the imminent shutdown from me, as it wasn't as widely spread in the news in the Netherlands, as it apparently has been in Google's home, the USA. So, why haven't Google+ users been shown the courtesy yet of being contacted about this important change via the e-mail account(s) associated with their accounts and Pages? tl/dr (4): Bring all of your user-base up-to-speed ASAP via a form of contact that is most likely to get their attention: e-mail. 5. Long filenames get cropped in the Google Takeout Archives: please add a metadata file that provides mappings from their shortened filename to their original filename Currently files with long filenames will get shortened to for instance "Cropped Filena(1).jpeg", resulting in a loss of metadata, as the original filename can no longer be restored. A simple metadata file which provides the original full filename for each shortened filenames, would solve this issue. It could be as simple as a plain text file with on each line: /path/to/Cropped Filena(1).jpeg: /path/to/Cropped Filename That Was Too Long.jpeg Though preferably a JSON file which not only contains the original and cropped filenames, but also an array of the Activity resources and other files in the archive it's associated with (such as relevant photo.metadata.csv and post.json files). tl/dr (5): provide a file that maps the cropped filepaths to their original filename/-path, and ideally also the other files in the archive it's associated with. *6. Provide tools and documentation for the Google+ Takeout Archives Currently the Google+ Takeout data (and Takeout data in general) is undocumented. (If there actually is documentation, it's too well-hidden). There also are no ready-made tools, such as commandline filter tools or scripting language libraries, available to read in the data for easy filtering and processing. Providing detailed documentation including what keys are always provided, which ones can optionally be expected (and in which situation), and what data type the values have (String, Integer, Time/Date/DateTime (and which (ISO) format), is paramount. Providing data model libraries for popular (scripting) languages such as Ruby, Python, Go, JS, C#, which can be used to load in the Takeout archive files, would come a long way towards helping users migrate their data to other alternatives. tl/dr (6): Please provide documentation and libraries to help process the Takeout data 7. Circles data is very limited Google+ Circles Export currently only contains: First Name, Last Name, Nickname, Display Name, and Profile URL This data is a small fraction of what is available to us currently on Users' profile pages. The Profile URL will likely become useless when Google+ is shutdown. Ideally this takeout will contain all data that is currently available to you (depending on the target user's visibility settings): Profile info: = First = Surname = Nickname = Display name as = Banner photo = Profile photo Personal contact info: = Phone number(s) = E-mail address(es) = Chat contact(s) details =Address(es) Work Contact Info = Phone number(s) = E-mail address(es) = Chat contact(s) details =Address(es) Work history = Company listing(s): == Name == Title == Start date == End date == Description Gender, date of birth and more: = Gender = Birthday (taking into account whether "Show year" is toggled or not) = Occupation Story =Tag line = Introduction (retaining rich text formatting) Skills = List of skills Link to album archive Education: = School/universities attended: == Name of school == Main course/field of study == Start date == End date == Description Sites: == Link(s) === Title === URL == Other profile(s): === Title === URL == Contributor to: === Title === URL === Current? toggle Especially the Sites data is paramount for users seeking to find their former followers / people they followed on new platforms. tl/dr (7): Add all missing profile information to Google+ Circles Takeout data 8. List of Followers: Maybe I've missed it, but I haven't been able to find a list of people who are following me yet, in the Takeout archives. This should ideally contain the same data as the above revised data for Circles. tl/dr (8): Add list of Followers along with their metadata, to the Takeout archive. 9. Why was the shutdown announced before the implications of it were clearly mapped out, and could be announced publicly? The way this was announced as side-note in a security blog, makes me wonder if this announcement was perhaps premature, and that not all implications w.r.t. integrations were actually clear yet. It would've been nice if there was more information to us from the start, as it would've resulted in less fear, uncertainty and doubt. — Dear +Google+: We're inviting you to comment to the G+MM community on what if any plans, commitments, capabilities, migration support, etc., Google are planning. My view has been that if Google don't provide some clarification within the first month of the announced shutdown, there's likely to be little if any support. There are three days left in that first month. The Google+ profile has not posted in three weeks, and its recent posts are locked against comments. I've reached out previously to Google directly through its press contact, with follow-up requests, specifically for Ben Smith, VP Engineering, or someone within his group to speak to G+MM. That request stands and is renewed here. As one of the moderators of this 3,000+ member community (all joined since 8 October 2018), we're very much hoping to hear from you, and soon. Normally our format is an Ask me Anything, but at the very least, and even if you don't have solid plans or schedules, we'd like to know what's in the cards, especially the following: Information on any features or capabilities of G+ to be disabled in advance of the final shut-down date. Presumably new-account formation will be among these, possibly new Community formation. The former is fairly understandable, the latter might be useful even at a late date in the migration for on-platform planning. Post-sunset availability of the G+ website itself. Will profiles and content still be Web-accessible? There's a substantial and long-lived set of content here, and a complete shutdown would be highly disruptive. Post-sunset access to users' Google+ data via Data Takeout. It's quite likely that not all users will have attempted, or succeeded, in creating and offloading their Google+ content. If it will still be able to create archives past the sunset date, this would be exceptionally useful information to have. Tools for migrating Google+ data to new platform(s). Numerous present G+ users would like to be able to migrate their personal posts, comments, photos, and other content to new platforms, likely to include other major social media platforms (Facebook, Twitter, SmugMug/Flickr, etc.), blogs (Wordpress, Dreamwidth, Blogger, Medium, etc.), and the emerging universe of open and federated platforms. These archives will almost certainly contain non-public data which could be at best embarrassing, and potentially personally catastrophic or worse, if made public. Tools for safely and responsibly handling large data archives are lacking, and the present instructions and data structures within the Google+ elements of Google Data Takeout fail to adequately support this process. We are aware of third-party efforts to create migration tools, including from G+MM members, and Tim Berners-Lee of Solid who has begun work on a G+ Data Takeout migration tool. What specific steps, tools, instructions, and data format changes are Google planning to ensure that this process is effective, efficient, responsible, and respectful of privacy? Further, are Google now taking steps to work with both proprietary and Free Software projects to provide for import tools? Present G+ users will need to store their G+ data takeouts prior to migration elsewhere as well as for some time afterward to ensure full restoration. One of the available storage options is Google Drive, and at the very least, holding G+ data on Google Drive should not change the security risks appreciably over their initial Google-based storage. The size of some archives will push many users over the free service tier of Google Drive capacity. Will Google commit to providing indefinite free storage of Google+ Data Takeout archives on Google Drive without registering the data storage against other user limits? Use of Google Drive also presents an opportunity for Google to provide on-system access and management of G+ Data Takeout archives. Given this, will Google commit to providing native tools for viewing, searching, filtering, extracting, and exporting Google+ archives from within Google Drive, including at least post, comment, image, video, collection, and contact data, as well as for distinguishing public from non-public content, and providing for export to leading endpoints including Facebook, Diaspora, Friendica, Markdown, and a standard minimally complex HTML format, with batch-process (rather than individual item) capabilities? (There are likely other elements I'm omitting from this list and I invite G+MM members to suggest other needs, say, HOA, chat, events, or other G+ features which may be of interest in preserving.) G+ specialised in image presentation and was immensely popular amonst photographers. Classification of photographs, and in particular, sorting through photographic archives is a challenging task, particularly at volume. Google have considerable experience in image processing and recognition. Will Google commit to providing descriptive search capabilities to photo and image collections, as well as other descriptive characteristics such as date, size, format, and EXIF metadata, for searching, organising, selecting, and exporting image collections? Naturally, the sensitive information which may result from such analysis should be limited in access to the archive's owner only and not be provided or made available to any other parties. Google Communities were a major feature of Google+ and range in size to millions of members, with over 5 million communities created. There is presently no mechanism for exporting G+ communities as a whole in any format. This might be of value to either community owners in reconstituting the community elsewhere, or to members wishing to retain access to years worth of contributions. Will Google commit to providing tools for Community owners and members to export G+ Community posts and texts in a useful format? Thank you.
+1'd comment on post by Julian Bond in Google+ Mass MigrationYou're channelling much of my thinking. Add in Tilly-Odlyzko; A refutation of Metcalfe's law. Argues for n * log(n) as network value function. I add in a constant per node cost, k, such that equilibrium size is reached where log(n) = k. Arity is a wonderful word. "Conversation scales poorly." (Observed by many. David Weinberger among them.) Information systems consist of messages existing as: • Transmissions propagated through space as variations over time. • Records propagated through time as variations over space. — Some thoughts on ways of categorising Social Networks along different dimensions. Network effects There is power in size. The question is, how much power? Metcalfe looked at it via the number of 1-1 connections possible and decided it was proportional to the square of the total number of nodes. This is one reason why Facebook or Twitter have more potential network power than G+. So the utility rise not just with N but N^2 Reed took this a stage further and looked at group forming and the total number of potential groups. The total number of possible groups is 2N - N - 1 suggesting that Utility rises in group forming networks at 2^N. However in real world networks nowhere near all possible groups actually form. In Social Groups it seems to me you need a minimum of 5 noisy people for the group to be self-sustaining. On the usual basis that 90% lurk, 9% Comment and 1% post, that means the real lower end is more like 50 people. At the upper end, Dunbar's number steps in as groups become too big for everyone to know each other. Somewhere around 150-250 people, groups tend to fragment. So as well as Social Networks gaining utility with N^2, if they support groups, their utility rises at somewhere between N^2 and 2^N. So for a Social Network to have long term utility we need lots of people able to form 1-1 relationships. And the ability to form small (5-250), long lived groups around common interests. The open question right now is whether we can build another truly large scale system (tens of millions of users, tens of thousands of groups) on top of a federated architecture or if this requires Google/Twitter/Facebook scale centralisation. https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Reed%27s_law One-Few-Many A long time ago now, I had the idea of categorising communication systems and platforms according to the numbers of creators and the number of consumers. Or authors and readers. Break each side into "One", "Few", "Many" and you have a 3*3 matrix of One-Few-Many authors communicating with One-Few-Many readers. So Private Blogs are typically One-to-Few. Big Media broadcast outlets are One-To-Many. Discussion forums are Few-To-Few. a person's experience of Feed aggregators is Few-To-One. Private messaging is generally One-to-One. eBay is Many-to-Many. Filling out all the cells in the matrix is an interesting intellectual exercise. The point though is that there are fundamental differences here between the various styles of comms. https://www.voidstar.com/node.php?id=2977 https://www.voidstar.com/images/onefewmany.gif Sync-Async Or Sync-real time, nearly real time, Async. How is the style of our comms defined by time? Chat and group chat (like IRC) happen almost in real time. People sometimes try and use Twitter or Email like this but it really doesn't work that way. We then bolt notification systems on top of this to try and speed up the responses and encourage people to respond immediately. But of course this breaks people's natural workflow. It also encourages a lack of thought in the reply. Often what's actually needed is a conscious decision to make the comms Async. Don't expect a reply in 24 hours and the reply you get is likely to be more thoughtful. Media Text, voice & image, video. There's a real problem with communications that use a tool that is too high up the stack here. This also relates back to the Sync-Async problem. Don't interrupt me with a voice message when I could skim read the text in my own time. But also don't use a screen shot just because of platform limitations (Twitter!). And don't do a 5 minute video to camera when 300 words would do that I could skim read in 20 seconds. But each media type as it's place. Your text review is no substitute for listening to the music or watching the film. But don't force me to watch the 45 minute TED talk to grok your 5 page idea. TL;DR. is bad, but TL;DV. is worse. Post Size Micro, Small, Long. There are fundamental differences in style between 140 chars, one screen of text and a 5 page essay. Every time we impose a limit the users will try and find ways round it. Hence Unroll, and reply-to-self /N conventions. Ideally, any one platform should support all these and not differentiate. In practice, dropping a 1000 word block into a chat doesn't work. But that's actually obvious. What isn't obvious but should be is that long form text is important. And somewhere in social networks there should be support for this. A long form post with semi-threaded short form comments below it is a highly successful pattern so should be supported.
+1'd comment on post by Julian Bond in Google+ Mass Migration"But don't force me to watch the 45 minute TED talk to grok your 5 page idea. TL;DR. is bad, but TL;DV. is worse." YESSSSSSSSSSSSSS!!! — Some thoughts on ways of categorising Social Networks along different dimensions. Network effects There is power in size. The question is, how much power? Metcalfe looked at it via the number of 1-1 connections possible and decided it was proportional to the square of the total number of nodes. This is one reason why Facebook or Twitter have more potential network power than G+. So the utility rise not just with N but N^2 Reed took this a stage further and looked at group forming and the total number of potential groups. The total number of possible groups is 2N - N - 1 suggesting that Utility rises in group forming networks at 2^N. However in real world networks nowhere near all possible groups actually form. In Social Groups it seems to me you need a minimum of 5 noisy people for the group to be self-sustaining. On the usual basis that 90% lurk, 9% Comment and 1% post, that means the real lower end is more like 50 people. At the upper end, Dunbar's number steps in as groups become too big for everyone to know each other. Somewhere around 150-250 people, groups tend to fragment. So as well as Social Networks gaining utility with N^2, if they support groups, their utility rises at somewhere between N^2 and 2^N. So for a Social Network to have long term utility we need lots of people able to form 1-1 relationships. And the ability to form small (5-250), long lived groups around common interests. The open question right now is whether we can build another truly large scale system (tens of millions of users, tens of thousands of groups) on top of a federated architecture or if this requires Google/Twitter/Facebook scale centralisation. https://en.wikipedia.org/wiki/Metcalfe%27s_law https://en.wikipedia.org/wiki/Reed%27s_law One-Few-Many A long time ago now, I had the idea of categorising communication systems and platforms according to the numbers of creators and the number of consumers. Or authors and readers. Break each side into "One", "Few", "Many" and you have a 3*3 matrix of One-Few-Many authors communicating with One-Few-Many readers. So Private Blogs are typically One-to-Few. Big Media broadcast outlets are One-To-Many. Discussion forums are Few-To-Few. a person's experience of Feed aggregators is Few-To-One. Private messaging is generally One-to-One. eBay is Many-to-Many. Filling out all the cells in the matrix is an interesting intellectual exercise. The point though is that there are fundamental differences here between the various styles of comms. https://www.voidstar.com/node.php?id=2977 https://www.voidstar.com/images/onefewmany.gif Sync-Async Or Sync-real time, nearly real time, Async. How is the style of our comms defined by time? Chat and group chat (like IRC) happen almost in real time. People sometimes try and use Twitter or Email like this but it really doesn't work that way. We then bolt notification systems on top of this to try and speed up the responses and encourage people to respond immediately. But of course this breaks people's natural workflow. It also encourages a lack of thought in the reply. Often what's actually needed is a conscious decision to make the comms Async. Don't expect a reply in 24 hours and the reply you get is likely to be more thoughtful. Media Text, voice & image, video. There's a real problem with communications that use a tool that is too high up the stack here. This also relates back to the Sync-Async problem. Don't interrupt me with a voice message when I could skim read the text in my own time. But also don't use a screen shot just because of platform limitations (Twitter!). And don't do a 5 minute video to camera when 300 words would do that I could skim read in 20 seconds. But each media type as it's place. Your text review is no substitute for listening to the music or watching the film. But don't force me to watch the 45 minute TED talk to grok your 5 page idea. TL;DR. is bad, but TL;DV. is worse. Post Size Micro, Small, Long. There are fundamental differences in style between 140 chars, one screen of text and a 5 page essay. Every time we impose a limit the users will try and find ways round it. Hence Unroll, and reply-to-self /N conventions. Ideally, any one platform should support all these and not differentiate. In practice, dropping a 1000 word block into a chat doesn't work. But that's actually obvious. What isn't obvious but should be is that long form text is important. And somewhere in social networks there should be support for this. A long form post with semi-threaded short form comments below it is a highly successful pattern so should be supported.
+1'd comment on post by Edward Morbius in PLExodus: The Beginning is NearIt's from trying to extend email and messaging clients to be things they weren't suited for that caused it. Trying to use Outlook as a document collaboration tool, calendar, LCS, poorly implemented SharePoint, quick and long form messaging not only in the same application but also the same delivery style and method, just all of it. Making email and email clients do anything beyond email is why email is useless now. — A farewell to email ...Regardless of how these specific experiments work out, one conclusion is clear. Even the people who are most tied to email are finding it increasingly unworkable in the world we have grown into. Administering an email installation while blocking spam and ensuring that one's emails actually get delivered is getting harder; fewer people and organizations want to take it on. As a result, our formerly decentralized email system is becoming more centralized at a tiny number of email providers. If "email" means "Gmail", it starts to lose its advantage over other centralized sites.... +Jonathan Corbet at LWN noting a trend I've been observing, and practicing, myself. Email is becoming less usable, less used, more problematic, and yet without a clear alternative, open or otherwise. This is only part of the Plexodus problem, though many dynamics are similar and for related reasons. https://lwn.net/Articles/768483/
+1'd comment on post by Edward Morbius in Google+ Mass Migrationhttps://github.com/FiXato/Plexodus-Tools will be the location for further updates to my jq library and other Google Takeout related tools. https://github.com/FiXato/Plexodus-Tools — A reminder: REQUEST JSON FORMAT for Google Data Takeout Google HTML is absolutely worthless. The instructions don't make this clear, but you're going to see this advice repeated repeatedly and repetitiously. With great frequency. Repeatedly. REQUEST JSON FORMAT for Google Data Takeout Why? Because the JSON format can be used by tools for extraction and import. Tim Berners-Lee is building one for Solid, there will be others. https://github.com/solid/solid-takeout-import (not yet usable, but in process). REQUEST JSON FORMAT for Google Data Takeout Why? Because the JSON format contains additional, useful, and critical fields for extraction and import to other sites and tools. REQUEST JSON SSSSSSSSCCCCCCccccrrrrraaaaaattttcccch...... <screeeech> Tap. Tap. Is this thing on? Hey folks, we interrupt this beat because I hear that you there, no, no, next to you, there, looking at your phone. Yeah, you, well, uh, I hear that you're thinking: "I don't know what JSON is." "I don't know what to do with JSON". "Heck, I don't plan to take any data out of Google. I'm gonna just #DoTheDataWalkaway ." Hey, cat, like, that's totally cool. I get it. I had a girlfriend who was all into that minimalism stuff. Wicked cool design ethic. But every time I wanted to fry an egg, I had to buy a new frying pan, 'coz she'd, like, donated the old one to charity or something? But she's moved on, and I like totally respect here and stuff.... Where was I? Oh yeah. But, y'see, we're not all like that. And some of us do know what to do with a JSON data extract. And we know that what it does is to make the information we want to use more accessible wherever else we want to use it. And there's a lot of folks who don't know this yet or are confused because, frankly, Google have messed this stuff up in how they do and talk about it. And those people need to know. And so when you're like "all, whatever man" out here on the dance floor, well, it kinda actually fucks shit up and stuff. So like, if you don't mind, please don't. Not here, anyhow? And even if we don't know what JSON is, or how to use it, what we know is that there will be tools created. Maybe by Google (we hope). Maybe by third party sites (and they're doin' just that). Maybe by a close personal friend. Maybe by a particularly talented housecat. But it's gonna happen, and JSON is the way. So. Go back to the phone. Do you important phone stuff. We'll leave you alone. We're cool with that. And let this be the message to the people doing the #GoogleDataTakeaway . Ya still wanna tawk about it? Start a new thread. Hip? Let's get this BEAT BACK ON!!! Let's get this BEAT BACK ON!!! Let's get this BEAT BACK ON!!! REQUEST JSON FORMAT for Google Data Takeout Why? Because Google's generated HTML is an ugly bastard stepchild of HTML that's not actually useful even as HTML. REQUEST JSON FORMAT for Google Data Takeout Why? Because you'll give yourself far more options and far fewer headaches down the road. REQUEST JSON FORMAT for Google Data Takeout Why? Because even if you can't make heads or tails of the output, the tools likely to be developed for intake to where you want the data to go will. REQUEST JSON FORMAT for Google Data Takeout Why? Because your friendly neighborhood hackers (and Space Alien Cats) can hack something together using 'jq' and 'awk' (or Python, Ruby, Perl, Go, ...) if all else fails. REQUEST JSON FORMAT for Google Data Takeout Why? Because it's what you actually want. REQUEST JSON FORMAT for Google Data Takeout REQUEST JSON FORMAT for Google Data Takeout REQUEST JSON FORMAT for Google Data Takeout (We need a have memes for this.) Where? Here: https://takeout.google.com/settings/takeout
+1'd comment on post by Al Tlön in Google+ Mass MigrationI thought I was reading ElReg. — Sheeesh "A petition on popular echo chamber Change.org is beseeching Google to keep on the official floggers-of-the-dead-horse that is Google+, for the benefit of the few agoraphobic dwellers of the baronies and fiefdoms within."
